Automated Behavioural Verification of Prolog Programs

Execution of a Procedure Let p c1; : : : ; cr be a procedure. The result Bout of the execution of p with in (where in is the input substitution of some abstract sequence B with hB; sei 2 Behp) is obtained by \concatenating" the results B1; : : : ; Br of the abstract execution of each clause. More precisely, Bout = CONC(B1; : : : ; Br), the last being a shortcut for CONC(: : :CONC(Br 1; Br) : : :). ( in) c1 (B1) ( in) ck (Bk) ( in) cr (Br) ...... Bout = CONC(B1; : : : ; Br) QQQQs 3 The procedure analyze_procedure succeeds if the computed abstract sequence Bout is more or equally precise than the abstract sequence B (with input substitution in). PROCEDURE analyze procedure(p;B; se) = for k := 1 to r do hsuccessk; Bki := analyze clause(ck; B; se) if there exists k 2 f1; : : : ; rg such that :successk; then success := false else Bout := CONC(B1; : : : ; Br) success := (Bout B) return success : The operation CONC is the counterpart for abstract sequences of the operation UNION, used in [18], which simply collects the information of two abstract substitutions into a single one. CONC di ers from UNION only for the computation of the number of solutions of a procedure which is the sum of the numbers of solutions of its clauses, not an \upper bound" of them. To obtain a good precision, we detect mutual exclusion of clauses [4, 17]. So, in the implementation of the CONC operation (see [14]), we compute the greatest lower bound of the ref of the two abstract sequences: if it is equal to ?, then the clauses are exclusive, and we only collect the numbers of solutions; otherwise, we compute the sum of the numbers of solutions for this greatest lower bound only. Abstract Execution of a Clause Let c p(X1; : : : ; Xn) f: g l1; : : : ; ls: be a clause and hB; sei be an element of Behp. Let also in be the input substitution of B. The execution of the clause c with in may be computed as depicted below. ( in) p(X1; : : : ;Xn) : B0 l1; (B1) : : : ; (Bk 1) lk; (Bk) : : : ; (Bs 1) ls (Bs) : (Bout) AAAA EXTC CCCC RESTRC @ @ @ @I RESTRG EXTGS k inter Bk aux @@R UNIF VAR UNIF FUNC @@ LOOKUP Let us see how the abstract sequences B0; : : : ; Bs, and Bout are obtained. B0 is obtained from in through the operation EXTC(c; in) which extends the domain of in to the set of all variables in c and returns an abstract sequence. Let k 2 f1; : : : ; sg. The operation used to derive Bk from Bk 1 depends on the form of the literal lk. Four cases apply. 1. lk is a literal Xi1 = Xi2 . In this case, we restrict the domain of the output out of Bk 1 to Xi1 and Xi2 and rename them into X1 and X2, by computing k inter = RESTRG(lk; Bk 1). Then, we execute the uni cation Bk aux = UNIF VAR( k inter). Finally, we compute the e ect of this uni cation on the output substitution out of Bk 1: Bk = EXTGS(lk; Bk 1; Bk aux ). 2. lk is a literal Xi1 = f(Xi2 ; : : : ; Xin). In this case, we use the same process as above where Bk aux = UNIF FUNC( k inter ; f). 3. lk is a non-recursive call q(Xi1 ; : : : ; Xim) where q 6= p. In this case, we restrict the domain of out to Xi1 ; : : : ; Xim and we rename them into X1; : : : ; Xm by RESTRG. Then, we look at sat and we search satq for the most precise abstract sequence Bk aux such that input(Bk aux ) k inter . If there is no such abstract sequence, we give up the analysis since there is not enough information in SBeh . The search for Bk aux is realized by the operation LOOK UP( k inter ; q; sat). Once we have obtained Bk aux , we compute the e ect of the call lk on Bk 1 by Bk = EXTGS(lk; Bk 1; Bk aux ). 4. lk is a recursive call p(Xi1 ; : : : ; Xin). In this case, we test whether k inter is less precise than in and, using the operation CHECK TERM(lk; Bk 1; se), we check whether for all h ; Si 2 Cc(Bk 1) and 0 2 Subst (S), se(hkXi1 0k; : : : ; kXin 0ki) < se(hkX1 k; : : : ; kXn ki): The last step is the computation ofBout fromBs, with the operation RESTRC(c; Bs) that restricts the output domain of Bs to the variables in the head of c. PROCEDURE analyze clause(c; B) = in := input(B) B0 := EXTC(c; in) for k := 1 to s do k inter := RESTRG(lk; Bk 1) if lk Xi1 = Xi2 then Bk aux := UNIF VAR( k inter) if lk Xi1 = f(Xi2 ; : : : ; Xim) then Bk aux := UNIF FUNC( k inter ; f) if lk q(Xi1 ; : : : ; Xim) and q 6= p then hBk aux ; successk i := LOOK UP( k inter ; q; sat) if lk p(Xi1 ; : : : ; Xim) then hBk aux ; success 0 k i := LOOK UP( k inter ; q; sat) successk := success 0k ^ CHECK TERM(lk; Bk 1; se) Bk := EXTGS(lk; Bk 1; Bk aoux) if there exists k such that either lk q(Xi1 ; : : : ; Xim ) ^ :successkor lk p(Xi1 ; : : : ;Xin) ^ (:successk _ kinter 6 in)then success = falseelse success = true and Bout = RESTRC(c; Bs)returnhsuccess; Bouti:The reader may refer to [14] for a detailed description of the algorithms.6 ConclusionsWe have sketched the main theoretical and methodological aspects of an analyser forProlog programs based on a veri cation approach. Implementing a complete analyseris a long term project. As we will attempt to complete such a project, we now discusswhat remains to be done.Analysing (Almost) Full Prolog. Since the correctness of our analyser is basedon the concrete semantics of [17], all Prolog features that are simple to model inthis framework can be easily integrated in the analyser. Arithmetic built-ins, suchas is and <, and test predicates, such as var and ground, belong to these features.Interestingly, most of them can be handled without additional coding by providingbehaviours capturing their operational semantics. The cut is a special control featurewhich requires to enhance the concrete and abstract domains with so-called \cutinformation". These aspects have been satisfactory solved in [4, 16, 17]. Thus we canintegrate a treatment of the cut based on the same approach into our analyser.Implementing a Complete Set of Domains. The abstract domain presented in thispaper is conceptually generic, since it is based on the approach of [6]. However theparticular instance that we have described is able to handle programs dealing withlists accurately, but not other programs. This restriction will be alleviated in thefuture by integrating a type domain similar to [13], as already described in [7]. Wewill also improve the treatment of sharing by adding a complementary domain forlinearity information. Finally, we will attempt to design more powerful domains forthe size components, based on non linear constraints and/or computer algebra.Extending the Veri cation Scope of the Analyser. Our analyser assumes that theoccur-check [2, 21] is performed during uni cation. It is nevertheless straightforwardto enhance the operations UNIF VAR and UNIF FUNC with an additional result param-eter specifying whether the occur-check is needed or not. Classical abstract domains(including sharing and linearity) will then allow us to solve the problem quite satis-factorily.Finally, our analyser cannot deal with non terminating procedures at all (i.e., it al-ways rejects them), but yet such procedures can sometimes be considered as correctif they \produce all their solutions" [12] or if the user is interested in merely \ex-istential" termination (i.e., the procedures produce at least one solution) [9]. Ouranalyser can be extended to such situations. This would allow one to transformexistentially terminating programs into (universally) terminating programs throughautomatic introduction of cuts. References[1] K.R. Apt. From Logic Programming to Prolog. Prentice Hall, 1997.[2] K.R. Apt and A. Pellegrini. Why the Occur-Check is Not a Problem. In M. Bruynooghe andM. Wirsing, editors,PLILP92, pages 69{86, Leuven, Belgium, 1992. LNCS 631, Springer-Verlag.[3] A. Bossi, N. Cocco, and M. Fabris. Norms on Terms and their Use in Proving UniversalTermination of a Logic Program. Theoretical Computer Science, 124(2):297{328, 1994.[4] C. Braem, B. Le Charlier, S. Modard, and P. Van Hentenryck. Cardinality Analysis of Prolog.In M. Bruynooghe, editor, Proceedings of the International Logic Programming Symposium(ILPS'94), Ithaca NY, USA, November 1994. MIT Press.[5] M. Bruynooghe. A Practical Framework for the Abstract Interpretation of Logic Programs.Journal of Logic Programming, 10(2):91{124, February 1991.[6] A. Cortesi, B. Le Charlier, and P. Van Hentenryck. Combination of Abstract Domains for LogicProgramming. In Proceedings of the 21th ACM SIGPLAN{SIGACT Symposium on Principlesof Programming Languages (POPL'94), Portland, Oregon, January 1994.[7] A. Cortesi, B. Le Charlier, and P. Van Hentenryck. Type Analysis of Prolog using Type Graphs.Journal of Logic Programming, 23(3):237{278, June 1995.[8] P. Cousot and R. Cousot. Abstract Interpretation Frameworks. Journal of Logic and Compu-tation, 2(4):511{547, 1992.[9] D. De Schreye and S. Decorte. Terminationof Logic Programs: the Never-EndingStory. Journalof Logic Programming, Special anniversary edition, 1994. Accepted for publication.[10] D. De Schreye, K. Verschaetse, and M. Bruynooghe. A Framework for Analysing the Termi-nation of De nite Logic Programs with respect to Call Patterns. In Proc. FGCS'92, pages481{488, ICOT Tokyo, 1992. ICOT.[11] S.K. Debray and N.W. Lin. Cost Analysis of Logic Programs. ACM Transactions on Program-ming Languages and Systems, 15(5):826{875, 1993.[12] Y. Deville. Logic Programming: Systematic Program Development. MIT Press, 1990.[13] G. Janssens and M. Bruynooghe. Deriving Descriptions of Possible Values of Program Variablesby Means of Abstract Interpretation. Journal of Logic Programming, 13(2-3):205{258, 1992.[14] B. Le Charlier, C. Lecl ere, S. Rossi, and A. Cortesi. Automated Veri cation of Prolog Pro-grams. Technical Report RP-97-003, Facult es Universitaires Notre-Dame de la Paix, Institutd'Informatique, March 1997.[15] B. Le Charlier and S. Rossi. Sequence-Based Abstract Semantics of Prolog. Technical ReportRR-96-001, Facult es Universitaires Notre-Dame de la Paix, Institut d'Informatique, February1996.[16] B. Le Charlier, S. Rossi, and P. Van Hentenryck. An Abstract InterpretationFrameworkWhichAccurately Handles Prolog Search-Rule and the Cut. In M. Bruynooghe, editor, Proceedings ofthe International Logic Programming Symposium (ILPS'94), Ithaca NY, USA, November 1994.MIT Press.[17] B. Le Charlier, S. Rossi, and P. Van Hentenryck. Sequence-Based Abstract Interpretation ofProlog. Technical Report RR-97-001, Facult es Universitaires Notre-Dame de la Paix, Institutd'Informatique, January 1997.[18] B. Le Charlier and P. Van Hentenryck. Experimental Evaluation of a Generic Abstract Inter-pretation Algorithm for Prolog. ACM Transactions on Programming Languages and Systems(TOPLAS), 16(1):35{101, January 1994.[19] B. Le Charlier and P. Van Hentenryck. Reexecution in Abstract Interpretation of Prolog. ActaInformatica, 32:209{253, 1995.[20] J.W. Lloyd. Foundations of Logic Programming. Springer Series: Symbolic Computation{Arti cial Intelligence. Springer-Verlag, second edition, 1987.[21] K. Marriott and H. S ndergaard. On Prolog and the Occur-Check Problem. SIGPLAN Notices,24(5):76{82, 1989.